home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000948_guido@cwi.nl _Thu Apr 22 23:52:07 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <guido@cwi.nl>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA08029; Thu, 22 Apr 93 23:52:07 MET DST
  4. Received: from charon.cwi.nl by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA28199; Fri, 23 Apr 1993 00:12:00 +0200
  6. Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
  7.     id AA12812 (5.65b/3.8/CWI-Amsterdam); Fri, 23 Apr 1993 00:11:58 +0200
  8. Received: by voorn.cwi.nl with SMTP
  9.     id AA01174 (5.65b/3.8/CWI-Amsterdam); Fri, 23 Apr 1993 00:11:56 +0200
  10. Message-Id: <9304222211.AA01174=guido@voorn.cwi.nl>
  11. To: timbl@nxoc01.cern.ch (Tim Berners-Lee)
  12. Cc: fine@cis.ohio-state.edu, www-talk@nxoc01.cern.ch
  13. Subject: Re: how should remote path names be handled? 
  14. In-Reply-To: Your message of "Thu, 22 Apr 1993 23:01:36 MET."
  15.              <9304222101.AA07208@ nxoc01.cern.ch > 
  16. From: Guido.van.Rossum@cwi.nl
  17. X-Organization: CWI (Centrum voor Wiskunde en Informatica)
  18. X-Address: P.O. Box 4079, 1009 AB  Amsterdam, The Netherlands
  19. X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax)
  20. Date: Fri, 23 Apr 1993 00:11:55 +0200
  21. Sender: Guido.van.Rossum@cwi.nl
  22.  
  23. Tim BL writes:
  24. >This is always what you expect, except that it might
  25. >surprise you if you don't think too hard that in directory
  26. >/a/fred, "bert" refers to /a/bert, not /a/fred/bert, so
  27. >/a/fred/bert should be referred to as "fred/bert" or "./bert".
  28. >Anyway, you are right, and if there are browsers which do otherwise
  29. >that is their problem, unless I've goofed.
  30.  
  31. The last example is really worrysome!  If you are trying to follow
  32. UNIX conventions, "./bert" should refer to the same thing as "bert",
  33. so it would refer to "/a/bert"!  What does the library code actually
  34. do?  (I don't have it handy!)
  35.  
  36. Another question about this subject is resolution of "../" prefixes.
  37. In the above example, what does "../foo" refer to?  I'd hope "/foo".
  38.  
  39. Also, who is supposed to do the ".." resolution -- the client or the
  40. server?
  41.  
  42. And what about "/../" in the middle of a path?  Does
  43. "/foo/bar/../bletch" always mean "/foo/bletch" (if "/foo/bar" were a
  44. symbolic link to a directory, it won't on UNIX, meaning that a client
  45. doing "../" stripping might wind up at a different place than a server
  46. blindly following the path (which might be dangerous if there are more
  47. "../" parts than allowed -- I don't know if servers allow this).
  48.  
  49. Finally, I believe there are (or were) some gateway servers on the net
  50. that are confused about this themselves: when in /a/b and attempting
  51. to generate a relative reference to c, they would end up referring to
  52. /a/b/c instead of /a/c, or when attempting to refer one level up they
  53. would point to /a/a instead of /a.  (I seem to remember the CERN Emacs
  54. Info gateway did this -- can't find where it is right now...)
  55.  
  56. --Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
  57.